The use of virtual machines (VMs) to improve the utilization of computing resources continues to increase. Such VMs can be characterized as software-based computing “machines” implemented in a virtualization environment comprising various hardware resources (e.g., CPU, memory, etc.). The VMs can operate based at least in part on the computer architecture and/or functions (e.g., operating system) of a real or hypothetical computer. Multiple VMs can operate on one physical machine (e.g., on a physical computer), with each VM sharing the resources of that physical machine across multiple environments. Various VMs can run multiple operating systems and/or multiple applications on the physical machine. Flexibility for such sharing can be facilitated at least in part by a hypervisor, which hypervisor allocates hardware resources dynamically and transparently to the running VM.
The high storage I/O (input/output or IO) demands of VMs has precipitated an increase in distributed storage systems that are implemented in virtualization environments. Specifically, such distributed storage systems can aggregate various physical storage facilities to create a logical storage pool where certain data may be efficiently distributed according to various metrics and/or objectives. Metadata describing the storage pool and/or its virtualized representations may be also distributed any number of times among various nodes in the distributed storage system. Many of these distributed storage systems implement various caching techniques to reduce the latency in accessing the foregoing data and/or metadata by the VMs and/or by certain components (e.g., storage I/O controllers) of the distributed storage systems. Specifically, multi-tier caching systems can improve the overall latency of operations by storing frequently used data elements in storage areas that correspond to observed access patterns. As an example, a dynamic random access memory (DRAM) can be used to cache items that are stored on hard disk drives (HDDs) to facilitate low latency access. In some cases, a given cache might be allocated across multiple tiers of storage facilities such as local (e.g., to a storage I/O controller) DRAM, local (e.g., to a node) solid-state drives (SSDs), cluster SSDs, local hard disk drives (HDDs), networked HDDs, and/or other storage tiers. In other cases, a cache in a distributed storage system might be partitioned into multiple cache partitions for various purposes.
Unfortunately, legacy techniques for sizing multiple cache partitions in a distributed storage system can be limited at least in their ability to address the performance by and between each of the multiple cache partitions. Specifically, the performance of a cache can be determined at least in part by the data access latency improvement resulting from the data being stored in the cache as compared to the access latency if the data were stored in a non-cache storage facility (e.g., networked HDD). Some legacy approaches for sizing a cache might merely facilitate allocating a fixed amount of memory for the cache and applying certain cache management techniques (e.g., least recently used or LRU, least frequently used or LFU, adaptive replacement cache or ARC, etc.) to determine whether or not to store and/or to retain a particular data element in the cache.
For example, the foregoing legacy techniques might allocate 1 GB of memory to a given cache and, when the cache is full, evict data elements from the cache based at least in part on a data element access time, access frequency, a combination of access time and access frequency, and/or other criteria. However, when a cache is partitioned for two or more data element types, or partitioned over two or more memory types, applying such legacy cache management techniques to the cache partitions might not achieve optimal overall performance by and between the cache partitions. This is because if a cache configuration/management policy is applied independently to the two or more partitions, then the relative importance of data items with respect to each individual cache partition to the overall system is not considered, which results in overall cache performance that may be less than optimal.
What is needed is a technique or techniques to improve over legacy and/or over other considered approaches. Some of the approaches described in this background section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.